\section{Tracker}

	\subsection{Principe d'un tracker}
	
	Un tracker est dans le cadre d'un réseau P2P, le chef d'orchestre. Il est le premier contact avec de nouveaux arrivants sur le réseau, il a autorité sur les fichiers présents sur le réseau. Sa mission principale est de fournir aux clients la liste des "seed" et des “leech”. C’est-à-dire la liste des fichiers proposés par les utilisateurs et la liste des fichiers en cours de téléchargement par les utilisateurs. Le tracker n’a cependant pas accès à ces fichiers et ne les héberge encore moins. 
	
	\subsection{Architecture du tracker}
	
	Un tracker doit pouvoir gérer plusieurs clients simultanément, on a donc une architecture basée sur des threads. Ces threads vont ouvrir une connexion avec le client, pour recevoir leur message puis le traiter avant d’envoyer une réponse. Le schéma ci dessous explique ce mécanisme : 
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.6]{img/arch_track.png}
	\end{figure}
	
	Chaque thread passe par trois phases pour calculer la réponse : Tout d’abord une phase de réception ou l’on assure que le message est complet et correctement formé, suivit d’une phase de parsing des données. Une fois les données acquises, on entre dans la phase de calcul de la réponse ou l’on renvoie au client l’information qu’il avait demandé.\\

	Le but d’un tracker étant de fournir des informations, il faut apporter de l’importance à ses informations et à leur stockage. Dans notre tracker, nous conservons deux types d’informations : des pairs et des fichiers. Les pairs représentent tout simplement les différents clients qui se sont connectés au tracker tandis que les fichiers représentent les informations sur les fichiers disponibles sur le réseau et surtout les pairs possédant les dit fichiers. D’un point de vue stockage, les pairs sont stockés dans une liste tandis que les fichiers sont stockés dans une hashtable où ils sont accessibles simplement en les recherchant par clef ( le hash du fichier ). Aucun mécanisme de sérialisation n’a été mis en place, il suffirait pour cela de sérialiser les deux structures de donnée précitées dans un fichier qui serait relu au lancement du tracker.  
	
	\subsection{Choix techniques et implémentation}
	
	Notre code C n’utilise aucune librairie externe. Nous nous sommes contenté d’utiliser les outils standards sous linux à savoir pthread pour la gestion des threads et les socket Unix pour les connections client/tracker.\\
	
	Nous avons choisi de créer une connexion par message plutôt que de maintenir le canal de transmission ouvert pour au final n’envoyer qu’un update toute les minutes. Ce choix permet d’éviter de congestionner le serveur si beaucoup de clients se connectent simultanément, de plus en cas de rupture de la connexion, le client n’a pas à repasser par la phase d’announce. Cette implémentation soulève cependant un problème causé par le protocole, en effet lorsque qu’un client émet un message d’update, il ne renvoie pas le port d’écoute qu’il utilise, nous sommes donc obligé de nous baser uniquement sur son adresse IP pour identifier le client, cependant cette identification n’est plus valable si plusieurs clients sont lancés sur la même machine en utilisant des ports d’écoutes différents. Une solution simple serait de renvoyer à chaque update le port d’écoute du client qui l'émet. \\
	
	Comme précisé plus haut, le traitement d’un message se fait en trois phase : une phase de réception et de vérification du message, une phase de parsing et de phase de calcul de la réponse. \\
	
	On retrouve beaucoup de contraintes sur la première partie, de la gestion du message Framing à la sécurité du logiciel en lui même. De plus le C propose des fonctions de gestions de chaînes de caractères archaïques ce qui ne facilite pas implémentation. Le fonctionnement de la première phase est décrit sur le schéma suivant : 
	
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.6]{img/aut_resp.png}
	\end{figure}
	
	Nous avons également fait en sorte que le logiciel soit protégé notamment des attaques par Buffer Overflow, les tailles des message sont ainsi constamment vérifiées et tout message trop grand pour un buffer est automatiquement refusé. On évite ainsi les risques de prise de contrôle du serveur à distance. Un autre point important pour le tracker est qu’il doit être résistant au fuzzing, en effet le tracker ne doit pas crasher à la première entrée erronée.\\
	
	La seconde phase à été plus simple à implémenter, elle transforme le message complet en données au format utilisé par le tracker pour pouvoir les traiter plus tard. L’implémentation n’a pas posé de problème particulier si ce n’est que là encore le manque de fonctions efficaces de gestion de chaînes de caractères se fait cruellement sentir. Dans cette partie encore, toute donnée incorrecte entraîne l'envoi d’un message d’erreur au client et le non traitement du message.\\
	
	La dernière phase est une étape de calcul de la réponse, cette étape est plutôt simple puisque l’architecture de l’application tourne autour de ce calcul, la recherche et l’ajout de fichiers sont gérés par la structure hashtable ( association clef / fichier ). Un défaut apparaît cependant dans la conception, lorsque l’on essaye de récupérer la clef d’un fichier en connaissant son nom. En effet cette opération n’était pas gérée par le type de donnée qui a dû être modifié. 